
AP State Enterprise Architecture 

... for a boundary-less information flow 


The Vision of the State of Andhra Pradesh is to use e-Governance as a tool to provide integrated 
services to its citizens through a free flow of Information, and to usher in an era of Good 
Governance. Designing an Enterprise Architecture is an essential first step in this direction. 









INTRODUCTION 
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“Enterprise Architecture is a framework for conducting analysis, design, planning and 
implementation of the vision, goals, strategies, functions, activities and desired outcomes 
of an enterprise, using a holistic approach at all times, such that the IT infrastructure and IT 
services are always aligned to the business strategies and business services, through 

standardization and integration” 

The real value of Enterprise Architecture is not in making better architectures...it’s in 
making a better enterprise. 

Enterprise Architecture is quite relevant to Government in so far as Government is an 
‘Enterprise of Enterprises’. EA enables a systematic and holistic development of a Portfolio 
of e-Governance Projects to provide integrated services to the stakeholders. Citizen- 
centricity is the essence of Good Governance. It involves building a 360 degree view of a 
citizen across all his touch-points with the government. Data should be modeled as a shared 
layer across all government departments and a cohesive citizen's profile should help all 
departments target the right citizens for the right services. 

This document presents a high-level view of the Andhra Pradesh State Enterprise 
Architecture (APSEA).The central theme of the APSEA is to provide “just enough” structure, 
which can be created “just in time” to meet the transformational requirements of the 
Government. APSEA shall be the Metamodel. The Architectures of various Enterprises 
(Departments and Agencies) are to be designed or re-designed so as to conform to the 
Metamodel. 

In so far as this is a high-level document, it is necessary for an Enterprise Architect (to 
be selected), to detail out several of the ideas presented in this document, mostly in 
consultation with the departments and agencies of the Government. For instance, the basic 
objectives and value proposition of each department, the services it intends to provide to its 
stakeholders in the TO BE scenario, the proposed service levels and KPIs, the TO BE 
decision-making processes, its position in the capability-maturity model, etc are to be 
documented and incorporated appropriately in the APSEA. 

APSEA is a journey, not a project. Let us take the first step... 





AP State Enterprise Architecture V 1.0 


1. SCOPE OF APSEA 


BREADTH 

The APSEA shall extend to all the departments of GOAP, its public 
enterprises and agencies that contribute to 80% of the business of 
governance, especially in relation to its interface with the citizens, 
businesses and the internal processes of Government connected 
therewith. An ABC analysis has to be done to identify the entities and 
the services and activities of each such entity that shall be included in 
the scope of the EA. 


DEPTH 

Typically, an architecture is a high-level document that should not lose 
itself in detail. However, it should not be too abstract to be useful to the 
developers. The eGov vision of GoAP is quite ambitious both in terms 
of its breadth and depth as also in terms Time-to-Benefit. Keeping 
these in view, the effort in developing APSEA shall lead to 

■ a comprehensive conceptualization of the spectrum of possibilities 
within the scope identified; 

■ identification of all the critical building blocks - technical and 
functional - that ensure a Whole-of-Government approach, 
interoperability, integrated service delivery, flexibility in 
development,simplicity and security 

■ design of all the systems that constitute the critical building blocks. 

■ assessment of Capability Maturity Levels of various departments 
and conducting a gap analysis 


DIMENSIONS 

Typically, Enterprise Architecture extends to 4 Domains: 


WHY DESIGN 
EA? 

The benefits that result 
from a good enterprise 
architecture include: 

• Efficiency 

• Productivity 

• Interoperability 

• Integration 

• Simplicity 

• Agility 

• Cost-effectiveness 

• Value-for-Money 

• Sustainability 

• Flexibility 

• Industry- 
friendliness 


■ The Business Architecture, which defines thegovernance goals, 
organization, and key processes. 

■ The Data Architecture, which describes the structure of the logical and physical data assets and 
data management resources. 

■ The Application Architecture, which provides a blueprint for the individual applications to be 
deployed, their interactions, and their relationships to the core government processes. 

■ The Technology Architecture, which describes the software and hardware capabilities required to 
realize the eGov vision, like IT infrastructure, middleware, networks, communications & standards. 


The present EA effort aims to extend to all the above 4 domains 
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2. VISION OF APSEA 


“Vision is the art of seeing the invisible” 

Jonathan Swift 


The Vision of the AP State Enterprise Architecture should truly reflect the Vision to establish Swarna 
Andhra Pradesh. While the framework for developing the APSEA should obviously begin with a 
visioning consultation, involving all major stakeholders within and outside the Government, the vision 
should contain the following elements: 

Aspirational 

■ The APSEA shall be an effective tool and one of the important frameworks in the realization of 
the vision of Swarna Andhra Pradesh. 

■ The APSEA shall be rated among the best in the world and lead to AP being ranked high on 
the e-Government Development Index globally. 

■ AP shall be known as an Innovation Society of global repute, with a focus on quality of life of 
its citizens, with a special emphasis on quality of education, healthcare, skill development, 
agricultural practices, infrastructure and services. 

Developmental 

■ e-Governance shall be a catalyst for enhancing the effectiveness of implementation various 
development projects and welfare schemes undertaken by the Government. 

■ Planning and/or monitoring of public sector schemes and projects shall be enabled to take 
advantage of the GIS and satellite imaging technologies. 

Citizen-Centric 

■ Citizens and businesses shall have a seamless and smooth interface with the Government. 

■ Departments and agencies of the Government shall be able to interoperate with ease and 
provide integrated services to the citizens and businesses. 

■ The medium of paper for interactions and correspondence should be reduced to the minimum 
in all the G2C, C2G, G2B, B2G and G2G areas. 

Inclusive 

■ Digital Divide shall be adequately addressed, especially leveraging the mobile technologies. 

■ APSEA should enhance the realization of participative and inclusive governance. 

■ Citizen Engagement should be accomplished with ease and cost-effectiveness. 

Technological 

■ Government and citizens shall be enabled to take advantage of the cutting-edge technologies 
like SMAC currently and those that emerge in future. 

■ The principles of open data, open standards and open APIs shall be ingrained in all the 
system development effort. 

■ Above all, the framework should ensure the right balance between information security and 
privacy of personal data. 
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3. ENTERPRISE ARCHITECTURE PRINCIPLES 

A. ORGANIZATIONAL PRINCIPLES 

Principle #1 : Primacy of Principles 

These principles of information management apply to all 
organizations within the Government. 

Principle #2 : Maximize benefit to the Government as a 
whole 

All decisions relating to information management are made to 
provide maximum benefit to the Government as a whole. Some 
organizations may have to concede their own preferences for 
the greater benefit of the entire Government. Applications and 
components should be shared across organizational 
boundaries. 

Principle #3 : Information Management is Everybody’s 
Business. EA is an Architecture of Architectures. 

All organizations in the Government participate in information 
management decisions needed to accomplish business 
objectives, and implement such decisions with full commitment, 
devoting the right and adequate resources. APSEA has a 
federated structure. It will focus on guidelines, mandates, 
standards, interoperability and integration. 

The option of designing APSEA as a single, monolithic architecture is infeasible and 
hence REJECTED. Respective Domain Owners and Managers shall develop their own sub¬ 
architectures following these principles, and federate the same to APSEA. 

Principle #4 : Common Use of Applications 

Development of applications used across the Government is preferred over the development of 
similar or duplicative applications, which are only specific to a particular department or 
organization. 

Principle #5 : Service Orientation 

The enterprise architecture is based on a design of services which mirror real-world activities 
required to conduct the business of Government. Service orientation places unique 
requirements on the infrastructure, and implementations should use open standards to realize 
interoperability and location transparency. 


WHAT ARE 

ARCHITECTURE 

PRINCIPLES? 

Architecture principles are 
a set of guidelines that 
reflect consensus across 
the enterprise. 

They govern the 
development, 
maintenance, and use of 
the enterprise 
architecture. 


A good set of Architecture 
Principles has the 
following 5 qualities: 

1. Understandable 

2. Robust 

3. Complete 

4. Consistent 

5. Stable 
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B. DATA PRINCIPLES 

Principle #6 : Data is an Asset. 

Data is an asset that has a specific and measurable value to the Government and is to be 
managed accordingly. 

Principle #7 : Data is Shared 

Users have access to the data necessary to perform their duties; therefore, data is shared 
across enterprise functions and organizations. It is less costly to maintain timely, accurate data 
in a single application, and then share it, than it is to maintain duplicative data in multiple 
applications. Shared data will result in faster and improved decisions since we will rely on 
fewer sources (ultimately one virtual source, i.e the Single Source of Truth) of more accurate 
and timely managed data for our decision-making. 

Principle #8 : Data Trustee 

Each data element has a trustee accountable for data quality.As the degree of data sharing 
growsand departmentsrely upon common information, it becomes essential that only the data 
trustee makes decisions about the content of data, and authorizes its modification. Information 
should be captured electronically once and immediately validated as close to the source as 
possible. Quality control measures must be implemented to ensure the integrity of the data 

Principle #9 : Common Vocabulary and Data Definitions 

Data is defined consistently throughout Government,and the definitions are understandable and 
available to all users. Defining Metadata and Data Standards (MDDS) within each domain 
assumes great significance. 

Principle #10 : Data Security 

Data is protected from unauthorized use and disclosure.Inaddition to the traditional aspects of 
national security classification, this includes, but is not limited to protection of pre-decisional, 
sensitive, source selection-sensitive, and proprietary information. 

Open sharing of information and the publication of information as per extant legislation must be 
balanced against the need to restrict the availability of classified, proprietary and sensitive 
information. 


“Shared Data leads to 
Faster Decision-making” 
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C. APPLICATION PRINCIPLES 

Principle #11 : Technology Independence 

Applications are independent of specific technology choices and therefore can operate on a 
variety of technology platforms. 

Principle #12 : Ease of Use 

Applications are easy to use.The underlying technology is transparent to users, so they can 
concentrate on tasks at hand. Standards on Usability should be adhered to while developing 
applications. Conformance to the Guidelines on Universal Electronic Accessibility shall be 
ensured. 


D. TECHNOLOGY PRINCIPLES 

Principle #12 : Requirements-Based Change 

Only in response to process/service needs are changes to applications and technology made. 

Principle #13 : Control Technical Diversity 

Technological diversity is controlled to minimizethe non-trivial cost of maintaining expertise in 
and connectivity between multiple processing environments. Policies, standards and procedures 
that govern acquisition of technology must be tied directly to this principle. 

Principle #14 : Interoperability 

Software and hardware should conform to defined standards that promote interoperability for 
data, applications, and technology. 

Standards help ensure consistency,thus improving the ability to manage systems and improve 
user satisfaction, and protect existing IT investments, thus maximizing returnoninvestment and 
reducing costs.Standards for interoperability additionally help ensure supportfrom multiple 
vendors for their products,and facilitate supply chain integration. 

A process for setting standards, reviewing and revising them periodically, and granting 
exceptions must be established. 


“Interoperability is sine qua non for Integrated Services” 
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4. ENTERPRISE BUSINESS ARCHITECTURE 

Business Architecture describes the service strategy, and the 
organizational, functional, process, information, and geographic 
aspects of the business environment. In the context of e- 
Governance, the term Business Architecture can be interpreted as 
the collage of relationships between Government and Citizens 
(G2C and C2G), Government and Businesses (G2B and B2G), 
Government and its Employees (G2E and E2G) and the internal 
processes of Government itself (G2G). Given that a Government is 
an enterprise of enterprises, these relationships and interfaces 
can number several hundreds. 

Any Government is characterized by certain quantitative and 
qualitative parameters that describe the nature and depth of the 
aforesaid relationships and interfaces. The task of the business 
architect is, therefore, to assess the current status of such 
relationships (both in quantitative and qualitative measures) and 
design a TO BE Business Architecture that seeks to transform 
all the relationships/ interfaces or a prioritized subset of the same. 


A. MACRO-LEVEL BUSINESS ARCHITECTURE 

In an enterprise of enterprises that a Government is, there are 
several functions, activities, services and applications (together 
called ‘artifacts’ for this purpose) that are exactly identical or similar 
or comparable across the various enterprises. Hence a macro-view 
of the business architecture of the Government would give us a 
chance to identify such artifacts and to transform them together, 
deploy them as common applications using the principles of cloud 
and shared resources, and also to optimize the effort, time and cost 
to develop them. 

An illustrative list of such common and/or cross-cutting applications 
and artifacts is given below: 

A1. Applications/Artifacts Common across the Government: 

1. Human Resource Management System 

2. Financial Management System 

3. e-Procurement 

4. Management of Logistics for governance 

5. Asset Management 

6. Litigation Management 

7. e-mail, video-conferencing and Calendar services 

8. Electronic workflow (e-Office) 


GOVERNMENT 
IS NOT A 
BUSINESS !! 

True! 

However, talking of 
Business Architecture 
makes an eminent sense 
in the context of designing 
and developing EA for 
e-Governance, for the 
following simple reasons: 

* Suffice it to say that term 
‘business’ is not used 
here in a narrow 
commercial sense, but in 
a broader sense to 
connote the functions, 
activities and 
responsibilities of the 
Government. 

* Governments had been, 
and increasingly, will 
have to adopt the 
principles of business 
management, to be more 
effective. 

* Governments are more 
process-intensive than 
the corporate sector, and 
the methods of process 
re-engineering, service 
transformation and 
customer(citizen)- 
centricity are, therefore, 
more applicable to 
governments than to the 
business sector! 

* Above all, citizens want 
their Government to be 
more ‘business-like’in 
dealing with their needs! 
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9. State Portal 

10. Right to Information 

11. Right to time-bound Services 

12. Identity Management for Employees 

13. Access Management Systems 

14. Attendance Monitoring Systems 

15. Employee Health Insurance 

16. Identity of Citizens for Delivery of Services/benefits 

17. e-Service Delivery Infrastructure 

18. Payment Gateway 

19. Mobile Gateway 

20. Information Security Management System 

21. Data Centre Services 

22. Cloud Services 

23. Wide Area Networks 

24. LAN & WiFi Services 

25. Cyber Security 

26. Knowledge Management (for public sector employees) 

27. Grievance Management System 

A2. Applications Common across Groups of Departments 

1. Social Benefits Management System 

2. Enterprise Project Portfolio Management 

3. Urban Land Management System 

4. Agricultural Land Management System 

5. GIS-based Systems 

6. Location-Based Services 

7. Name-based Systems 

8. Sector Promotion Services 

9. Educational Institutions Management System 

10. Content Management System 

A3. Cross-cutting Applications 

1. House Building Permission 

2. e-Biz - Single-window clearances for setting up business/industry 

3. Registration of Land-related deeds 

4. Nutrition Programs for women & children 

5. Agricultural loans& insurance 

6. Integrated Criminal Justice System 

7. Disaster/ Emergency Management Systems 

8. Government Land Management System 

Principles #2 and #4 (stated in Section 3 on EA Principles) squarely deal with the requirements for 
design and development of the 3 categories of applications/ artifacts specified above. It is 
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necessary to resist the temptation and / or pressure to continue with the legacy systems in silos or 
to build ‘pipes’ between them on the plea that they are time-tested applications. Such a view is 
short-sighted and takes the steam off the business case for the EA exercise, and therefore, 
should be resisted. 


B. MICRO-LEVEL BUSINESS ARCHITECTURE 

A number of micro-level business decisions or resolutions, illustrated below, play a critical role in 

developing the Business Architecture 

1. BPR for all the 3 categories of applications listed in the previous section shall be done in a 
generic/ cross-cutting manner so as to optimize the benefits to all the targeted stakeholders/ 
users. The BPR teams shall deal with the related departments, forms and processes 
simultaneously so as to normalize the processes across all the agencies. Elimination, 
Simplification, Optimization, Workflow Automation, Self-Service and Integration shall be 
the thumb rules for such a process transformation. 

2. The well-established concepts like single-sign-on, digital signatures, and emerging technologies 
like SMAC should be taken advantage of in all possible ways, following the practice of 
technology-led innovation. 

3. The concept of Mobile-First shall be observed religiously while designing any service or 
redesigning an existing service. 

4. All processes, and more so the complex processes, shall be broken down to their elemental 
components. Such Elemental Government Processes (EGPs), which may not number more 
than 20 across all the processes of Government, shall be re-engineered and transformed to be 
highly efficient and transparent, so that transforming the more complex processes becomes 
automatic and trivial. 

5. Customer-centric design, efficiency, convenience and service orientation shall dictate the way 
BPR is done. This is more relevant for design of online forms, workflows, service centres, 
payment systems, customer feedback systems etc. Citizen Services should be customized to 
suit the profile of different categories and classes of citizens, like Students, Farmers, Business 
People, Self-Helf Groups, Pensioners etc 

6. Governance should be modeled around the end-to-end holistic lifecycle processes for the 
governed entities i.e. birth to death for citizens encompassing all the services that a citizen 
avails, initiation to closure for commercial establishments etc 

7. A quick secondary research on the best practices in the areas identified for BPR, is 
recommended. 

8. Service Levels and Performance Metrics shall be recommended for each service/process, 
duly benchmarking against the best in the world. 

9. Standard Business Modeling techniques, most suited to each domain must be adopted for 
documenting the re-engineered processes, each assigned an enterprise-wide Code. 

10. BPR at the granular level of EGP and at the business process/ service level shall be enforced 
uniformly and consistently in all works relating to system development and implementation. 

11. Every process/ service shall be delivered in multiple channels, giving a wide variety of choice to 
the end users. The axiom of Mobile First should guide this effort. 
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5. ENTERPRISE DATA ARCHITECTURE 

Data Architecture is, by far, the most critical component of the 
Enterprise Architecture, in so far as data leads to information and to 
knowledge and is the basis of providing any service in the digital 
world. Government, seen as an Enterprise of Enterprises, has 
some unique characteristics around the data it holds: 

• Large in size & Large number of datasets 

• Complex & Diverse 

• Interdependent 

• Sensitive 

• Held by innumerable entities 

• Most sought-after 

• Requiring a long shelf-life 

• Dynamic 

As a result of the above unique characteristics, designing the 
Enterprise Data Architecture for the Government is quite involved. 
Therefore, the creation, storage, transportation, updation, archival 
protection and management of data should be founded on sound 
Data Principles. 

Principles 6 through 10 of Section 3 above, lay down certain 
universal commandments about data management. The following 
additional principles shall be observed while designing the 
Enterprise Data architecture: 

1. Data Architecture should rest on a group of carefully identified 
Core Datasets. The core datasets are those, which contain 
data elements that occur most commonly used in the 
applications of several enterprises of the Government. These 
are, the data elements that describe the attributes of 

a. Parcels of Land-Urban and Agricultural 

b. People 

c. Establishments 

d. Employees 

e. Geospatial Data 

f. Things (as in Internet of Things) 

In view of the seminal importance and critical nature of the Core 
Datasets, they need to be defined, standardized, collected, 
protected and maintained with utmost care and detail. The 
schemas for the Core Databases are to be designed with equal 
care. Especially, it is to be noted that the Aadhar Database has 
a national footprint, and is increasingly becoming the de facto 


HALF THE JOB 
IS DONE WHEN 
YOU GET THE 
DATA 

ARCHITECTURE 
RIGHT !! 

Data is to an information 
system as the blood is to the 
body! 

* Data should be pureand 
shall remain pure always 

* Data should 
circulateamong the 
entities as freely as 
possible, following the 
principle of seamless 
access to all those 
authorized to use it. 

* All data should conform 
to the data definition 
standardsnotified, so as 
to promote 

interoperability and to 
minimize the ETL efforts. 

* A well-designed Data 
Governance 
Modelshould be put in 
place, specifying the 
‘owners’ and ‘users’ of 
each dataset. 

* Above all, data should 
be securefrom loss, 
corruption, unauthorized 
access, theft and 
misuse. 
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standard for identification of people. The Government of Andhra Pradesh had created a State 
Resident Data Hub (SRDH), as a mirror image of the Aadhar database. Due credence has to be 
given to the SRDH, while defining the Core Dataset relating to People. Annexures V, VI and 
VII describe the methods recommended for creating, maintaining and managing the Core Data 
on People, Land and Entities. (The methods relating to GIS and Things need to be specified). 

2. Enterprise Master Data is next in importance. Master Data is relatively invariant data, which is 
used to identify geographic locations, entities, and all kinds of information, which can be 
represented as a standard code. The number of Master Datasets can be quite large for an 
enterprise like the Government, as it relates to / emanates from the functions of various sectors 
or departments. A singular and integrated/joint effort has to be made across the Government 
agencies to locate, identify and/or create Master Data for each domain, like Health, Education, 
Infrastructure, Energy and Transportation. The following precautions have to be taken, while 
defining the Master Datasets 

a. The Master Datasets already defined at the International level (like country codes, ICD 
Codes, etc) and the National Level (Like the Census Codes, Postal Zip Codes etc) shall 
be adopted as they are. 

b. The Master Datasets already notified by the Govt of India, and the Government of AP 
shall be taken cognizance of. 

3. In view of the core nature and critical architectural importanceof the Core Datasets and the 
Master Datasets, the following additional precautions need to be taken in their management. 

a. The metadata relating to both should be positioned in the Enterprise Architecture 
Artifact Repository (described later). 

b. The ownership and management responsibilities of these datasets should be clearly 
defined and enforced. 

c. Modifications to the datasets shall be permitted only in a fully controlled manner with 
appropriate audit trails. 

d. Special security arrangements shall be made to protect the core and master data. 

e. Disaster Recovery and Business Continuity Plans for both these Datasets should be 
planned carefully and on a priority. 

4. Domain Databases: In addition to the core and critical datasets specified above, it is necessary 
to identify the important databases of all domains, departments and agencies that are 
essentially required to build the applications specified in Section 4 on Business Architecture. 
For each of the identified databases, a Database Schema needs to be prepared. A schema is 
the definition of a collection of database objects viz, the tables, fields, relationships, views, 
indexes, packages, procedures, functions, queues, triggers, types, sequences, materialized 
views, synonyms, database links and directories. When the APSEA is being detailed, the 
Schemas for all the Core Datasets, the Master Datasets and the Domain Databases need 
to be specified, duly considering the definitions and structures of the existing databases 
and schemas, and normalizing them across the domain or across the Government as the 
case may be. 

5. Data Models: In order that we derive the maximum benefit out of the EA effort, significant 
attention has to be paid to the design of a comprehensive Data Model that incorporates all the 
architecture principles stated in this document. Appropriate Data Models shall be designed at all 
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the 3 levels viz, the Conceptual Data Models, the Logical Data Models and the Physical 
Data Models. 

6. Other important artifacts of Database Architecture: In addition to the above architecture 
work, it is necessary for the Enterprise Architect to design the following artifacts in relation to the 
Database Architecture: 

a. Data Access Model: This model defines the principles on which access rights shall be 
given to different roles in the database administration. These rights shall be defined 
precisely in respect of all the Core Datasets and Master Datasets. 

b. Data Lifecycle Model: This model defines the standard processes for the creation, 
maintenance, updation, archival and deletion of data, with a special emphasis and detail 
in relation to the Core Datasets and the Master Datasets. 

c. Data Security Model: This model defines the types of controls (per ISO 27005) that 
need to be incorporated in the design of various databases, so as to ensure 
conformance to the highest standards of security. The ISMS should be clearly 
articulated in respect of all the Core Datasets and the Master Datasets. 

d. Data Migration Model: When an existing application is replaced, there will be a critical 
need to migrate data (master, transactional, and reference) to the newapplication. The 
Data Architecture should identify data migration requirements and also provide 
indicators as to the levelof transformation, weeding, and cleansing that will be required 
to present data in a format that meets the requirements and constraints of the target 
application. 

7. Metadata: Metadata is ‘data about data’. It occupies a pivotal role in the design of Data 
Architecture. A well-designed, standards-based metadata repository is an invaluable asset to 
application developers. To this end, the Enterprise Architect shall design Metadata for the 
APSEA. Domain specific metadata standards and Dublin Core Standard shall be adopted for 
this. 

8. Target Data Architecture: The Data Architecture designed keeping in view all the above 
principles as also the architectural vision, shall provide a holistic view of how the business 
objectives and vision set out in this document will be realized. Since the legacy systems, 
numbering hundreds across the Government had been designed and implemented over a 
period of a decade, and as such, consist of different technologies, platforms, data models with 
differing levels of rigor in observing the database principles, migration to the target data 
architecture can be quite a complex process. Besides this, it entails a great degree of change 
management effort, as the organizations resist any major changes in such a fundamental thing 
as data structure. The Enterprise Architect has therefore, to create appropriate plans of data 
migration and change management in close coordination with the major stakeholders. 

9. Issues in Creation & Maintenance of Core Data: Implementation of the concept of Core Data 
is fraught with several problems, and raises several issues, which needed to be anticipated and 
addressed. These are in the nature of the Source and Ownership of Core Data, Data 
Standards, Maintenance of the Core Data in as pure a form, Authenticity and legal status of the 
Core Data etc. These issues are addressed in Annexures V to VII in respect of the 3 types of 
Core Data, viz, People, Land, and Entities (issues relating to GIS and Things to be identified). 
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6. ENTERPRISE APPLICATION ARCHITECTURE 


An application architecture describes the structure and behavior of 
applications used in an enterprise, focused on how they interact with 
each other and with users. 

This involves defining the interaction between application packages, 
databases, and middleware systems in terms of functional coverage. 
Application architecture seeks to manage how multiple applications are 
poised to work together. 


PRINCIPLES OF APPLICATION ARCHITECTURE 

1. Packaged Applications shall be preferred to custom-built 
applications. 

2. Process Reform / re-engineering shall precede any custom¬ 
building effort. 

3. Customizations to application products should be minimum; 
instead the business logic of the user-agency has to be 
modified to align with the features of the package. 

4. An end-to-end-view of the business functionality has to be 
taken and not a fragmented/ service-level view. E.g - request to 
fulfilment. 

5. Applications shall be designed to be modularin structure and 
based on componentization. 

6. Encapsulating components shall be avoided. 

7. Components, modules and applications shall be reused across 
the enterprise. To this end, Enterprise Process Objects 
(EPOs) shall be developed and reused in all applications, 
requiring the functionality given by each EPO. 

8. Web-services Architecture or Service Oriented Architecture 
shall be adopted by default. 

9. Mobile Application Architecture shall be deployed by default, 
wherever we have large citizen interface. 

10. Applications shall have channel and device independence. 

A Target Application Architecture shall be developed adopting the 
above principles. To supplement such architecture, the following 
matrices shall be prepared. 


WHAT IS THE 
JOB OF THE 
APPLICATION 
ARCHITECT? 


Application Architect is to an 
enterprise, as a structural 
engineer is to the layout of a 
large industrial plant. He has 
to design how the individual 
applications of the enterprise 
are to be laid out and the 
interconnections between 
them. 

More specifically, he/she has 
to 

• Design a set of 
principles for designing 
and developing the 
Enterprise Application 
Architecture. 

• Prepare a portfolio of 
applications that deliver 
the services targeted by 
the enterprise business 
architecture 

• Explore possibilities of 
re-using applications 
across the enterprise. 

• Identify and map the 
interrelations and 
interoperability 
requirements between 
various applications 

• Design the external 
interfaces to the 
applications 


1. Application-Organization Matrix, to show which departments/ 
agencies require/use each of the applications in the portfolio. 

2. Role-Application Matrix, to show what role each actor plays in 
each application 

3. Application-Interaction Matrix, to show which applications talk to other applications and for what 
purpose. 
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4. Application-Functionality Matrix, to show the discrete services and functions that each 
application delivers/ performs. 


TARGET APPLICATION ARCHITECTURE 

A high-level Target Application Architecture designed for APSEA is shown in Figure 1 below. This 
takes into consideration, the 3 categories of business applications listed in Section 4 dealing with 
Business Architecture. It also recognizes the fact that currently, the Government of AP is in the process 
of designing a development plan for the State for the next 15 years and that one of the strategies is to 
constitute 7 Missions to produce tangible progress in the 7 broad areas identified, namely, Primary 
Sector, Social Empowerment, Skill Development, Services Sector, Manufacturing, Infrastructure 
and Urban Development. 
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Figure 1: AP Enterprise Application Architecture (Logical View) 

The following statements supplement the understanding of the above application architecture 

1. The Schematic does not claim to be representing the entire portfolio of applications that 
eventually constitute the application architecture of APSEA. It is only representative of the 
logical layout of the Enterprise Application Architecture. The Enterprise Architect shall have 
to populate each block fully, after a detailed but quick survey. 

2. The 5 horizontal blocks in the lower half, represent 24 common applications/ core datasets that 
all departments and agencies have to use on the principle of “develop/ procure once, use 
across the enterprise”. These 5 blocks represent the application services relating to 
Infrastructure, Support, Core Data, Establishment and Productivity. 
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3. The Block on the top left, represents the ‘Group Applications’ that are to be designed and 
developed in common for groups of departments with comparable or similar functions. An 
example is the Welfare Group of Departments consisting of the Social Welfare, Backward 
Classes Welfare, Minorities Welfare, Women & Child welfare etc. Annexure 1 gives a more 
exhaustive list of such groups, along with the functionalities/ services which are common across 
each group. 

4. The Block of Seven Missions represent seven broad sectors, aligned to the Vision of Swarna 
Andhra Pradesh. Each Mission consists of 3 to 5 major Government Departments, and 5 to 10 
agencies. Annexure 2 (to be completed) gives the Mission Statement of each Mission, together 
with the constituent departments and agencies. Each of the Missions may have to develop /use/ 
procure a core application and a number of subsidiary applications. The list of such 
applications needs to be prepared and hyper-linked to these 7 pillars. 

5. The Block captioned “Other Agencies”, represents all the other departments and agencies of the 
Government, which do not fall within the scope of the 7 Missions. 

6. The horizontal bars represent the Cross-cutting applications that depend on more than one 
department for delivering a service or set of services. Again, only a representative list of such 
cross-cutting applications has been shown in the Figure 1. It is necessary for the Enterprise 
Architect to interact with the departments and come out with an exhaustive list of cross-cutting 
applications that need to be part of the APSEA. 

7. Retiring a large number of discrete applications by the departments and agencies may be 
necessitated as a result of the effort involved in the Enterprise Architecture. This is simply on 
account of the introduction of the concepts of Common Applications and Group 
Applications. Just as it is important to identify the new applications, which are needed to fulfil 
the vision of the new State, it is equally, if not more important to identify the departmental 
applications/ web-sites/ service centres/ call centres etc, which have the same or similar or 
comparable functionality of one of the common or group applications. Such stand-alone 
applications have to be abandoned or phased out. Once such an ‘Abandon List’ is identified, a 
migration and change management plan will be required to be put in place to reach the target 
architecture. There is likely to be stiff resistance from some quarters, especially from those used 
to an application for a long time. Commercial arrangements may also have to be reworked. 

8. Critical Assessment of Existing Applications is essential before they are proposed to be 
carried forward to the Target Architecture, as otherwise, any ‘non-standard application’ would 
lead to sub-optimal results or create avoidable problems of interoperability in course of 
time. Annexure 3 provides the list of major applications currently deployed in Andhra Pradesh, 
showing the software environment and maturity level. 

The following criteria should be included in the checklist for assessing the existing applications, 
a. Whether the functionality provided by the existing application is provisioned in one or 
across more than one of the common applications of the Target Application 
Architecture? 
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b. Whether the data structure and definitions used in the existing application conform to the 
data standards notified or proposed to be notified? 

c. Whether the application complies with and/or conforms to the Architecture Principles 
defined in Sections 3C and 3D? 

d. Whether the application has adopted the national/international standards applicable to 
the domain? 

e. Whether the application has been built after re-engineering the business processes? 

f. Whether application-level security has been built into the application? 

9. Only those existing applications that satisfy ALL the above criteria should be retained in the 
Target Architecture and upgraded as necessary. All other applications shall be abandoned and 
the required functionality has to be developed as an extension of the applications retained or 
built as a fresh application. 

10. Existing applications should not be made to comply with interoperability or other requirements of 
the EA, through a workaround like placing the application in a wrapper. 


RESPONSIBILITY OF APPLICATION ARCHITECT 

The basic responsibility of the Application Architect is to design the Application Architecture in a fine 
grain, beyond what is represented in the Figure 1. This responsibility involves undertaking the following 
tasks: 

1. All the Common, Group, Mission, Cross-cutting and other applications shall be represented in a 
complete shape, incorporating all the major functionalities forming the Vision of APSEA. Further, 
each application shall be drilled down to one or two levels to bring out the functionality of each 
application and the interrelationships and interactions between each application and all the 
related applications. 

2. The Application Architect shall prepare the 4 matrices that characterize the functionality of each 
application and its interactions with other applications, viz, Application-Functionality Matrix, 
Application-Organization Matrix, Role-Application Matrix and Application-Interaction Matrix. 

3. All the Applications in the portfolio shall be represented in the UML 2.x Standard notation, with 
a complete set of Diagrams -Structure Diagrams, Behaviour Diagrams and Interaction 
Diagrams, as depicted in Figure 2. 
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Figure 2 : UML Diagrams to be used to represent Application Architecture 

4. The Application Architect shall finally verify and certify that all the interaction requirements 
demanded by the Common Applications that would be used by all the Departments and 
agencies, the Group Applications that would be used by groups of departments and agencies 
and Cross-cutting Applications that will be used by the member departments that deliver one or 
more Integrated Services, are completely met. The Architect shall, alongside represent the 
standards, protocols and interfaces that each such interaction shall comply with. 

5. Finally, the Application Architect has to conduct a Stakeholder Consultation, in groups of 
related stakeholders given the large size of the Government, understand the impact that the 
Target Application Architecture will have on the stakeholder organizations and elicit the views of 
the stakeholders on (i) the degree of fit of the proposed Application Architecture with the 
business needs of the Stakeholder, now and in future and (ii) the feasibility of implementing the 
Target Application Architecture considering the constraints that stakeholder organizations have 
in terms of resources, capabilities and preparedness for change. The views of the stakeholders 
gathered during the consultation may suitably be incorporated in the proposed Target 
Application Architecture, to give it a final shape. 
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7. ENTERPRISE TECHNOLOGY ARCHITECTURE 


Enterprise Technology Architecture is a collection of technology 
building blocks, positioned and/or sourced in such a manner as to 
enable us to achieve the Enterprise Vision. 

The technology landscape of Andhra Pradesh, like that of any 
enterprise in the public or private sectors, is characterized by a 
collection of legacy systems of different vintages, located in 
geographically dispersed manner and not capable of easy integration. 

In the context of development of AP Enterprise Architecture towards 
realization of the vision set forth in the Section 1, it is necessary to 
envision and move towards an Integrated Information Infrastructure 
(i 3 ). i 3 enables a Boundary-less Information Flow, i.e, getting 
information to the right people at the right time in a secure, reliable 
manner, in order to support the operations that are core to the 
enterprise. It is akin to the “Boundary-less Organization’ conceptualized 
by Jack Welch in Generic Electric. It does not imply that there are no 
boundaries, but that they should be made permeable. 

Integrated Information Infrastructure is based on the principle that it is 
no longer good enough to maximize the service efficiencies in each 
department taken individually.lt isnecessary to optimize the service 
efficiencies of the entire Government taken as a single unit. We 
can gain significant operational efficiencies and improve the many 
different business processes at the enterprise-level —both internal 
processes, and those spanning the key interactions with customers and 
partners — if only we could provide the users with: 

■ Integrated Information so that different and potentially conflicting 
pieces of information are not distributed throughout different systems 

■ Integrated Access to that information so that users can access all 
the information they need and have a right to do so, through one 
convenient interface. 

The problem space sought to be addressed by the i 3 can be illustrated 
by the following set of requirements of the Vision of the Government of 
Andhra Pradesh: 


TOO MANY 
TECHNOLOGIES 
& CHANGING BY 
THE DAY!! 


The human urge for 
continuous innovation and 
invention is driving the 
exponential growth of 
technologies in the ICT 
space. New technologies 
descend on the scene much 
before the earlier 
technologies are absorbed 
by the business systems and 
end-users. 

Gartner predicts the 
following 10 trendsin 
technology during 2015-17: 

1. Tablets 

2. The Infinite Data Center 

• Logical Growth 

3. Energy Management 

4. Mobility 

5. Hybrid Clouds 

6. Fabric Data Centers 

• Integrated Functionality 

7. IT Complexity 

8. Big Data 

• Deduplication 

9. End of Service Desks 

• Reactive to Proactive 

10. Software-Defined- 
Networks 

Any upcoming work on 
Enterprise Architecture has 
to take note of these trends. 


a. Citizens shall have single-sign-on access to all the 
services that they need; 

b. We should move towards a “certificate-less society”, 
or more extremely, towards “service-less services”. To elaborate, currently, most of the 
students obtain several certificates like caste certificate, income certificate and nativity 
certificate before they can apply for an admission to an educational institution or for a 
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scholarship. These certificates, which are today delivered as ‘services’ can be done 
away with if all the educational institutions were enabled access to the databases 
containing the information on caste, income and nativity of students. The example of the 
student-related ‘services’ applies with equal force to a myriad of ‘services’ that citizens 
and businesses receive today, be it online and be it with the least effort. 

c. We should aim to establish an online single-window system of clearances required to set 
up a business. 

d. We should have an integrated view of all the benefits being received by a household 
from the Government to be able to take policy decisions to streamline the same. 

e. We should have real-time cross-departmental information on area of crops grown and 
the water utilized from the public irrigation sources, to achieve a more efficient water 
management. 

f. The list of such examples can go on till it constitutes a majority of the e-Services being 
delivered today by the Government or of the MIS requirements of the Government. 

Much of the wish list like the one above can be fulfilled if only we have the Integrated Information 
Infrastructure spanning the ‘Whole-of-Government’. 

Figure 3 gives a logical view of the proposed Integrated Information Infrastructure / . An explanation of 
the same follows. 


Integrated Information Infrastructure i 3 

(Logical View) 
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Figure 3: Integrated Information Infrastructure/ for AP 
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The e-Highway is a piece of infrastructure that translates the idea of / into its technical counterpart. It 

enables an easy and transparent way of virtually integrating the datasets of disparate applications. The 
following notes make this clear. 

1 . e-Highway is actually a custom-built middleware that acts as a conduit between the Information 
Consumer Applications and the Information Provider Applications, across the Whole-of- 
Government. 

2. e-Highway has 3 basic components - the Information Exchange, which is a standards-based 
gateway, the Access Control List, which validates the rights of the consumer and the provider 
in relation to exchanging the data in each proposed exchange and the Information Directory, 
which is a standards-based registry of all datasets that are registered by their owners for 
positioning in the exchange pool along with the metadata of each dataset. Since the 
registrations and searches are limited to the super-users within the Government, and to an 
extent to the developer community, it may be adequate to adopt the UDDI standard. Optionally, 
the Semantic Web Service matchmaking technologies can be adopted. 

3. The Core Datasets relating to Land, People, Entities and GIS will be available for access 
directly by all the applications comprising the Portfolio of APSEA, but through a security layer. 
These are required by almost all the applications. Hence a direct access without the medium of 
the e-Highway reduces complexity and overheads. 

4. The Open Datasets are sets of data that are to be put in the public domain by law or policy of 
the Government. The data should be pushed on to the Open Data Platform automatically as and 
when it gets generated, and NOT in a batch mode or at will. All users can use the same through 
the open access. Private developers can develop applications in the C2G and B2G space using 
this facility. 

5. It is to be noted that any application in the APSEA Portfolio can be an Information Provider 
Application or an Information Consumer Application depending on the context. The logical 
division of applications into these 2 categories, represented in Figure 3 is for better 
comprehension of the functionality of the e-Highway. 

6. The design of the e-Highway should be based on the cloud technologies, considering that 
most of the applications in the portfolio move towards the cloud sooner or later. 

7. The e-Highway will play a pivotal and central role in the realization of the vision of the Enterprise 
Architecture. It is necessary, therefore, to design it with care and implement with urgency. In this 
regard, the National Service Delivery Gateway and the State Service Delivery Gateway 
initiatives have to be studied and evaluated whether, with appropriate modifications and 
enhancements, they can play the role of e-Highway, in the interim or in the Target Architecture. 

The Enterprise Architect has to design and size all the components of the e-Highway. 
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BUILDING BLOCKS OF TECHNOLOGY ARCHITECTURE 

As alluded to earlier, the Technology Architecture is a collection of Technology Building Blocks 
(TBBs) that are designed to work in unison and seamlessly. The Architecture, thereby, also becomes 
modular in structure and admits of easy extension, expansion, enhancement or replacement in parts, 
with technological advancements. The TBBs are selected keeping in view not only the current business 
requirements and available technologies but also the future requirements and technologies. The idea is 
to ensure that the technological foundation so laid should sustain and grow over a period of the next 10 
years, before a need arises for it to be redesigned and re-laid. The technology trends indicated in page 
18 are quite relevant in this regard. 

1. Compute, Storage and Platform Infrastructure: The aspirational vision of APSEA brings 
certain imperatives, which need to be kept in view while evaluating alternative options for the 
basic infrastructure like the compute power, storage capacity and platforms required. These 
imperatives are 

a. The reorganized State of Andhra Pradesh does not have any data center in its 
territory. It is currently hosting all its applications, data, websites and other soft 
infrastructure in the State Data Centre at Hyderabad. AP should plan for a state-of- 
the-art data center in its territory. 

b. The realization of the aspirational vision of APSEA demands establishing a State-of- 
the-Art Data Center at the earliest. Any delay in establishing the basic infrastructure may 
delay the proper implementation of the APSEA. 

c. Most of the capabilities and functionalities delineated by the business architecture and 
the application architecture require the infrastructure services provided by a Cloud- 
enabled Data Center of Tier-4 level. 

Considering the above, the following options emerge: 

i. Option 1 : Build a State-of-the-Art Cloud-enabled Data Center ground-up in AP. 

ii. Option 2: Meet the requirements of APSEA by procuring the Data Center Services 
from an existing Tier-4 Data Center in India. 

iii. Option 3: Promote establishment of a State-of-the-Art Cloud-enabled Data Center of 
Tier-4 Class in AP, adopting a PPP Model, and obtain its services. 

Among the 3 options, Option 3 appears to be the most effective, as it avoids CapEx, can 
secure a highly concessional rate for the various DC services through the PPP arrangement 
and brings the benefits of the latest technologies not only to GoAP but also to the industry in 
AP.Tier-4 DC assures availability of 99.995%, besides operating at a PUE (Power Usage 
Effectiveness) of about 1 . 2 , among the best in the world. 

The establishment of the Tier-4 DC as above will meet the infrastructure requirements of 
APSEA in terms of Compute Power, Storage Capacity, besides bringing all the benefits of Cloud 
Computing. 

2. Middleware: The requirements of middleware, which enables Application Integration, is 
achieved through the establishment of the e-Highway, as detailed in the foregoing sub¬ 
section. Estonia, which is rated among the best in the world in implementing e-Governance, had 
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established the middleware called X-Roads, several years ago. The e-Highway aims to achieve 
more impressive results by adopting the latest technologies like the Cloud-computing, combined 
with the functionality of a traditional middleware product. 

3. Security: APSEA will depend heavily on the Internet for achieving its vision. Moreover, 
extensive LANs and WiFi networks are to be created in various public buildings. With the 
increased use of Internet as the medium for providing services, and the near-ubiquitous use of 
Internet by the citizens, cyber security assumes great significance. The Critical Information 
Infrastructure is to be guarded more specially so as to ensure continuous availability of the 
critical services, like the power, transportation, water, medical services, e-Gov services etc. The 
GOI has notified a comprehensive policy on cyber security in 2013. All the same a 
complementary cyber security policy has to be designed for implementation and enforcement at 
the State level, in respect of the critical services provided by the State Government, some of 
which have been mentioned earlier. The objectives of the AP State Cyber Security Policy are (i) 
to ensure the strict adoption of cyber security measures by all agencies dealing with digital 
assets, (ii) to provide for regular security drills and audits (iii) to create enhanced awareness 
among the citizens through education and publicity (iv) to facilitate the production of cyber 
security professionals through the educational institutions in the State and (iv) to establish 
robust security for the e-Governance systems in the state. 

The approach to cyber security at the State level should comprise of working on several 
strategies like 

a. aligning with the GOI efforts on Cyber Security; 

b. establishing organizations like State Computer Emergency Response Team (S-CERT), 
Centre for Security of Critical Information Infrastructure, sectoral S-CERT’s for critical 
sectors like power, water supply, healthcare, Police, Treasuries, e-Governance, 
Transportation and Disaster Management; 

c. Establishing a Security Operations Centre (SOC) and 

d. Giving an increased focus on citizen awareness, security education and training. 

4. Networks & Connectivity: The vision of the Government of AP is to provide integrated 
services to the citizens and businesses and more significantly, to enhance the quality of 
education and healthcare and to increase productivity in the primary sector. All these call for a 
robust connectivity - connectivity of the Government functionaries at all levels and connectivity 
of the citizens to the Internet i.e connectivity within the Government and connectivity with the 
Government. The completion of the National Optical Fibre Network project of the Govt of India 
assures a Gigabit connectivity upto the Panchayat level. From the perspective of the 
Technology Architecture of the APSEA, it is necessary to provide for the connectivity 
requirements within the Government. The Network Architecture should address this. 

The following points merit consideration in this regard. 

a. Network architecture refers to the layout of the network, consisting of the hardware, 
software, connectivity, communication protocols and mode of transmission, such as 
wired or wireless. For such a complex enterprise as the Government, designing an 
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appropriate Enterprise Network can be quite an elaborate task. Hence it is necessary to 
engage a team of network specialists to design the network for APSEA. 

b. Bandwidth Requirements: The promotion of cloud environment leads to the logical 
consequence of the bandwidth requirements of various agencies varying dynamically. 
The traditional model of provisioning fixed bandwidth on a point-to-point basis does not 
hold any longer. Hence it is necessary to indicate a range for the bandwidth 
requirements of Government agencies of different agencies, as attempted in the Table 4 
given below. These indications may be kept in view by the network architects. 


SI 

No 

Category of Government Office 

Range of bandwidth 
required 

1 

AP Secretariat 

5-10 GBPS 

2 

Large HOD / Head Office of PSU 

1-5 GBPS 

3 

District Offices 

0.5-1 GBPS 

4 

Mandal Level Offices 

100 MBPS 

5 

Gram Panchayat Level Offices 

8-22 MBPS 

6 

Village-level Offices 

2 MBPS 


Table 1- Indicative Bandwidth Requirements of AP Govt Offices (2015-20) 

c. Software Defined Networks: The APSEA has a lofty vision as set out in Section 2. It is 
abundantly clear also that the Enterprise Architecture has to be Future-Proof. There is a 
compelling case for including the emerging network technology viz, the Software Defined 
Network, moving away from the traditional hierarchical network architectures. The 
following are some of the compelling reasons in favour of SDN. 

i. Software-Defined Networking (SDN) is an emerging Network Architecture, 
which is dynamic, manageable, cost-effective, and adaptable, suitable for the 
high-bandwidth, dynamic nature of cloud-based applications. ‘SDN architectures 
decouple network control and forwarding functions, enabling network control to 
become directly programmable and the underlying infrastructure to be abstracted 
from applications and network services’. 

ii. Conventional network architectures are getting increasingly complex to 
manage and static in terms of bandwidth provisioning. 

iii. Complex policies: The complexity of today's networks makes it very difficult for 
IT to apply a consistent set of access, security, QoS, and other policies to 
increasingly mobile users, which leaves the enterprise vulnerable to security 
breaches, non-compliance with regulations, and other negative consequences. 

iv. Changing traffic patterns: Within the enterprise data center, traffic patterns will 
change significantly. In contrast to client-server applications where the bulk of the 
communication occurs between one client and one server, the applications of the 
APSEA access different databases and servers to deliver Integrated Services. 
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v. Consumerization of IT; Users are increasingly 
employing mobile personal devices such as 
smartphones, tablets, and notebooks to access 
the enterprise network. We have to 
accommodate these personal devices in a fine¬ 
grained manner, while maintaining security. 

vi. Big data demands more bandwidth: Handling 
the "big data" needs of APSEA requires massive 
parallel processing on the servers, all of which 
need direct connections to each other. 

The network architects shall seriously evaluate the need to 
incorporate the SDN technology in part of the enterprise 
networks that demand dynamic provisioning, centralized 
management and rapid scaling. 

5. Cloud First: Increasingly, Governments all over the world are 
adopting Cloud. In the paper “Federal Cloud Computing 
Strategy” published on Feb 8, 2011, the US Chief Information 
Officer had spelt out the WHY, WHEN and HOW of migrating to 
the Cloud environment. Several Countries have published their 
cloud strategies as well. The Government of India has published 
an approach paper and an implementation Roadmap for Cloud 
Computing, in 2012. The GOI has also launched its first Cloud 
implementation called MeghRaj in 2013. 

A phased approach to adoption of cloud is recommended. The 
following principles apply. 


a. The evaluation in terms of the deployment model 
should be laaS first, followed by PaaS and SaaS. 

b. The evaluation in terms of the business model 
should be Private Cloud first, followed by Hybrid 
Cloud. Public Cloud may be the model of last resort. 

c. The adoption of cloud/sharing can go along the 
following sequence: 

i. Commodity IT like websites design and 
hosting, Infrastructure & asset management, 
e-Mail, and helpdesk; 

ii. Support IT like document management, HR 
management and Financial Management; 

iii. Mission IT like healthcare, Geospatial data 
and Performance Management. 

d. The eventual state of cloud-enablement of the Government will be through migration 
to the Cloud-enabled Data Center, as already recommended in the foregoing para 1. 


EVERYONE IS 
TALKING OF CLOUD! 

Cloud computing is defined 
by the National Institute of 
Standards and Technology 
(NIST) as 

“a model for enabling 
convenient, on-demand 
network access to a shared 
pool of configurable 
computing resources (eg, 
networks, servers, storage, 
applications, and services) 
that can be rapidly 
provisioned and released 
with minimal management 
effort or service provider 
interaction 

The five essential 
characteristics of cloud 
computing are on-demand 
service, broad network 
access, resource pooling, 
rapid elasticity, and 
measured service. 

Cloud computing 
technologies are offered in 3 
models, in terms of the 
degree of ‘control’ the owner 
of the information has on the 
content - Infrastructure as a 
Service (laaS), Platform as a 
Service (PaaS) and 
Software as a Service 
(SaaS) 
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In the interim, GoAP will do well to participate actively in the MeghRaj initiative of 
GOI and cloud-enable the existing SDC at Hyderabad, 
e. Each major department should be asked to choose 3 applications for migrating to 
the Cloud by March 2015. 

It is strongly recommended that the Enterprise Architect conducts a quick analysis of 
existing applications and prepares an action plan for migration to the cloud. 


6. Platform for Integration with Social Media: Social Media has shown a meteoric rise over 
the last few years. The power and reach of these media can’t be overemphasized. 
Governments across the world are beginning to use social media effectively for 
establishing a relationship with their constituents, leading to the realization of the 
concept of e-Governance (distinguished from e-Government), coined over a decade 
ago. Social Media is the foremost among the emerging technologies, namely the SMAC 
technologies. The Blueprint for Electronics, IT and e-Governance published by GoAP in 
July 2014, gives adequate emphasis to adoption of Social Media by the Government 
agencies. While a broad framework and focused approach in a few selected 
departments to the use of Social Media might be the immediate necessity, as recommended 
in the Blueprint, eventually managing multiple departments interacting with multiple channels of 
social media may pose an issue of scale and consistency. It is necessary therefore to create a 
Social Media Gateway for the use of Government officials in their interactions with the citizens. 
Such a gateway will be one of the important TBBs in not long a period. The Social Media 
Gateway may only contain the minimum functionality like registration of Govt users, the 
platforms they intend to use and themes they would discuss in each channel. It may also 
contain an analytics engine that gives the Government functionaries a clear idea of the public 
opinion on any current or emerging topic. 

The Enterprise Architect has to formulate the functional requirements of the Social Media 
Gateway. 

7. Design, Development and Management of Websites: Websites form a useful source of 
information about the Government agencies. Some websites and portals enable transacting 
online with the Government agencies. However, a majority of the websites are found to be not 
user-friendly or not updated with the required frequency. While guidelines do exist for the 
development and maintenance of web-sites, the ground realities are different. We need to put in 
place a framework for design and development of all important web-sites of the Government 
satisfying the minimum criteria. The APSEA should aim to promote the following: 

a. Web standards notified by the standards setting bodies like W3C, IETF, ISO, Ecma 
International, Unicode Consortium and Internet Assigned Names Authority (IANA). 

b. Development guidelines notified by Govt of India through GIGW- Guidelines for Indian 
Government Websites) (web.guidelines.gov.in) 

c. The web-site design principles issued by the UK Government, with emphasis on user- 
friendliness and citizen-centricity. ( https://www.qov.uk/desiqn-principles) 

d. Ease of access from mobile devices 
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e. Periodic audit of the web-sites from the perspective of security, quality of content, user- 
centricity and currency of information. 

Content Management System shown as part of the Application Architecture can be made use of 
for compliance with the requirements of consistency of information across different web-sites of 
the Government and currency as needed/ defined in the GIGW. 


8. Technology Standards: Standards are the bedrock on which the foundations of inter¬ 
operability are to be laid. Fortuitously, AP is one of the early States to have recognized 
the critical role of Standards. All the same, given the importance of concepts like single¬ 
sign-on, smoother interface with government for availing a variety of services, and the 
overarching need for Government to take advantage of big data analytics for policy 
formulation, standards become all the more important. It is, therefore, necessary to 
create a policy framework for development, adoption and enforcement of Standards in 
the eGov domain. Given the blurring boundaries between the services provided by 
Government and the private service providers, aka telecom and Internet service 
providers, health and education service providers, it is necessary to establish common 
interoperable standards so as to add to the convenience of the citizens. The policy 
can also emphasize the criticality of Open Standards so as to avoid vendor lock-in and 
to ensure seamless integration of disparate applications, products and systems 
developed/deployed by different organizations and vendors. 

Interoperability, single-sign-on, future-proofing, cost-effectiveness, data portability, 
enhanced efficiencies, cross-sectoral mapping and analysis, ease of coordination and 
collation at the national level are some of the more important benefits of the policy. 

The work done by GOI in the area of Standards viz, Interoperability Framework for e- 
Governance (IFEG), Meta Data and Data Standards (MDDS), Localization Standards, 
Biometrics Standards for Fingerprints and Iris, may be adopted. A continuous watch 
may be kept on the emerging standards, create self-policing mechanisms for enforcing 
the standards, and provide for making concerted efforts at developing integrated and 
joined-up services that put the standards ecosystem to test and gainful use. 

It is necessary for the Standards Governance Body to lay down the Standards in the 
following areas: 

• Business(Domain) Standards: 

o Standard shared domain functions 
o Standard role and actor definitions 
o Security and governance standards for business activity 

• Data Standards: 

o Standard coding and values for data 
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o Standard structures and formats fordata 
o Standards for origin and ownership of data 
o Restrictions on replication and access 

• Applications Standards: 

o Standard/shared applications supporting specific business functions 
o Standards for application communication and interoperation 
o Standards for access,presentation, and style 

• Technology Standards; 

o Standards for hardware products 
o Standards for software products 
o Standards for network products 
o Standards for software development 

The Enterprise Architect has to prepare a complete list of Technology Standards required 
for implementation of the APSEA. 
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8. IMPLEMENTATION GOVERNANCE 

Implementing the State Enterprise Architecture will be quite arduous, complex and time-consuming, 
given the wide scope, breadth and depth of the Target Architecture. A well-designed Architecture 
Governance has to be put in place. Implementing the APSEA can be considered to be a Program, in so 
far as it consists of 3 phases (described below) and as many as over 50 individual projects to be 
implemented in close coordination. It needs political will of a very high order bestowed on the program 
over a significant period of say, 2 to 3 years. 

The implementation of the Enterprise Architecture is typically spread over 3 distinct phases. 

Phase I: Design of Enterprise Architecture: The initial phase relates to the detailed design of a full¬ 
blown Enterprise Architecture. While this document gives a reasonably clear idea of the scope of work, 
and describes the components and building blocks required to be put in place, several of the 
architectural pieces have to be refined, architectural gaps filled and all the building blocks are to be 
drilled down to the next level of detail. The deliverables of the Implementation phase (Phase II) have to 
be defined with a great deal of certainty and precision. A significant and critical effort is also involved in 
the stakeholder consultation, before the Enterprise Architecture is ‘finalized’ and pushed into the 
implementation phase. The consultation process should involve the policy makers of all the major 
departments of the government, key representatives of the IT industry, Subject Matter Specialists (in 
the business domains and not technology domains) and eminent persons from the academic 
community. 

The initial phase also involves estimating the resource requirements - both financial and human 
resources- for the implementation phase and obtaining an ‘in-principle’ approval of the competent 
authority. 

• A high-level group, which may be called the Enterprise Architecture Design Group (EADG), 
will have to be constituted with the representatives of the stakeholder groups specified earlier. A 
precisely-defined TOR and workable timelines will have to be handed over to the EADG. 

• Since this phase involves a great deal of detailing and consultation, it is necessary for the 
Government to retain the services of a consultant firm(specialized in formulating technical 
strategies for large enterprises) that has experience in designing Enterprise Architectures of the 
size and complexity contemplated for APSEA. The major deliverables of the selected consultant 
firm are shown in the Annexure 4. 

• The Phase I involves intensive discussions, brainstorming, coordination with the stakeholders 
and seeking approvals at various stages. It is highly advisable that a team of IT Experts is 
positioned within the Government (ITE&C Department) to be called the Enterprise 
Architecture Support Group. This Group will be in position for a period of 3 years to provide 
the required continuity and consistency across the various activities of the APSEA work. The 
Group should consist of upto 6 experts, with a combined experience of over 100 years in the 
areas like Enterprise Architecture, Business Process Modeling, Software Engineering, emerging 
technologies like SMAC, Contract Management, and in Program/ Project Management. The 
need for instituting a State CIO can’t be over-emphasized in this context. 
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Phase II: The Implementation Phase: The Phase II involves the preparation of detailed designs, 
coding, testing, procuring and deployment. It is estimated that Phase II will involve undertaking of over 
50 individual projects of different categories, namely, building infrastructure blocks, application blocks 
and support blocks or capacity building. The following recommendations are made in this regard: 

a) Prioritization & Phasing: The Enterprise Architecture Landscape is quite large. It can’t be done all 
at a time. It is necessary to prioritize and phase it over 3 to 5 years. The following principles for 
prioritization may be applied: 

i. Projects/ initiatives that have a direct bearing on the integration of service delivery may be 
given top priority - e.g e-Highway, Core Databases, Open Data Policy. 

ii. Projects that are core out of the common applications may be given the next priority, e.g 
Core Databases, e-Office, Mobile gateway. 

iii. Projects/ initiatives that will have wide-ranging involvement of citizens may be given the 
next level of priority- e.g Social Media Gateway; Policy on use of Social Media by Govt 
depts; crowdsourcing for creation of identified public digital assets. 

iv. Common Applicationsother than those identified at (ii) may be given the next priority. 

v. Other projects may be prioritized in terms of the size of their interface with the stakeholders. 

b. All the projects in the portfolio shall be slotted in 3 phases- Phase I, Phase II and Phase III. The 

phasing may be done keeping the following principles: 

i. The prioritization as above may be kept in view. Projects in Priority (i) and (ii) may be kept in 
Phase I; those in Priority (iii) and (iv) may be kept in Phase II and the rest in Phase III. 

ii. Projects, which are already in a steady state of implementation and can be brought in 
complete alignment with the APSEA with a marginal effort may be included in the Phase I. 

iii. Projects for which a special line of funding would be available may be included in Phase I 
or Phase II, depending on the lead time for the funding to flow in. 

c. Project Development Fund: Very often, precious time is lost initially to get funding support for the 
design and development of the project i.e, conceptualization, defining services and service levels, 
designing the architecture of the project, and crafting the bid documents. The cost of these efforts 
may be less than 5% of the project cost. However, a lot of tie is taken in the approval process. The 
aggregate of the delay across the portfolio of projects in each phase may be so large as to 
jeopardize the implementation plan as also the logically planned sequence of implementation and 
thereby make the architecture suboptimal in its effectiveness and impact. To short circuit such 
problems arising out of delays in initial approval, it is strongly recommended that a Project 
Development Fund of Rs 50 cr may be created along with constitution of an Empowered Group 
charged with the responsibility of taking time-bound decisions on the approval of the project 
development effort for ALL the projects in the approvedportfolio. 

d. Procurement Policy: A clear policy has to be laid down for procurement of various components, 
building blocks, products, licenses and applications and of services. In the absence of an agile and 
flexible procurement policy, implementing the APSEA would soon become nightmarish and we get 
lost in procedural knots and tangles. The policy should 

i. provide for a short procurement cycle of 30-45 days; 
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ii. enable pro bono development of components or applications by 
entrepreneurs; 

iii. place significant reliance on PPP Model; 

iv. prefer BUY to MAKE 

v. prefer BUY SERVICES to BUY PRODUCTS; 

vi. parallelize several procurements so as to shorten the implementation time; 

vii. encourage dependence on crowdsourcing in as many areas as possible. 

e. Program Management: An Enterprise Portfolio and Project Management tool, specially designed 
for IT projects may be selected and deployed for monitoring the scores of projects and initiatives 
which will be on hand at any point of time. 

TIMELINES 

Enterprise architecture work at the National Level or a State Level has been observed to take 2 to 3 
years at the fastest, and has extended to 10 years in some countries. Given the special requirements 
and pressing needs of the new State of Andhra Pradesh, the following very aggressive timelines are 
suggested for implementation. 


SI No 

Milestone 

Timeline 

1 

Appointment of Enterprise Architect 

30 Sep 14 

2 

Approval of Detailed APSEA 

31 Dec 14 

3 

Implementation of Phase 1 

30 June 15 

4 

Implementation of Phase II 

30 Dec 15 

5 

Implementation of Phase III 

30 Dec 16 
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Annexure I 

Services of Group Applications (PI see Section 7) 


SI No 

Group 

Application 

Participating Departments 

Services 

1 

Welfare 

■ Social Welfare 

■ Tribal Welfare 

- BC Welfare 

■ Minorities Welfare 

■ Women & Child Welfare 

■ Rural Development 

■ Differently-abled Welfare 

■ Weaker Sections Housing 

■ Social Pensions 

■ Scholarships 

■ Benefit Schemes 

■ Nutrition 

■ Wage Guarantee 

■ Livelihood 

Improvement 

2 

Portfolio Project 
Management 

■ Planning Department 

■ Irrigation Dept 

■ Roads & Buildings Dept 

■ Infrastructure Dept 

■ ITE&C Department 

■ CS Office 

■ CM Office 

■ Portfolio 

Management 

■ Project Management 

■ Development 

Planning 

■ Monitoring & 

Evaluation 

3 

Land 

Management 

■ Revenue Dept 

■ Registration Dept 

■ Survey Dept 

■ Agriculture Dept 

■ Irrigation Dept 

■ Industries Dept 

■ Commercial Banks 

■ Cooperative Banks 

■ Record of Rights 

■ Registration of Deeds 

■ Mutation of rights 

■ Farm Loans 

■ Infrastructure 

Planning 

■ Crop Planning 

■ Ayacut Development 

4 

Sector 

Promotion 

■ Industries Dept 

■ ITE&C Dept 

■ Tourism Dept 

■ Infrastructure & 

Investment Dept 

■ Handlooms & Textiles 
Dept 

■ Investment 

Promotion 

■ IT Promotion 

■ Electronics 

Promotion 

■ Tourism Promotion 

■ Handlooms & 

Handicrafts 

Promotion 

5 

Content 

Management 

■ Higher Education Dept 

■ Intermediate Education 

■ School Education 

■ Technical Education 

- MOOCs 

■ e-School 

■ Digital Literacy 

■ Knowledge Portal 

■ Skill Development 



■ All Departments 

■ Website Content 

Management 
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Annexure II 

7 Missions ( PI see Section 7) 


SI No 

Name of the Mission 

Constituent 

Departments 

Core Application(s) 

1 

Primary Sector 



2 

Social Empowerment 



3 

Knowledge & Skill Development 



4 

Services Sector 



5 

Industries Sector 



6 

Infrastructure Sector 



7 

Urban Development Sector 
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Annexure III 

Partial list of existing Online Applications in AP (PI see Section 7) 














1 

ITE&C 

A P State Portal 

www.ap.gov.in 

MS Sharepoint 2010, 

SQL Server 2008 R2 

A 

2 

ITE&C 

AP Online 

aponline.gov.in/apportal/i 

ndex.asp 

Microsoft Technologies 
ASP.NET 

A 

3 

ITE&C 

MeeSeva 

meeseva.gov.in 

Microsoft Technologies 
.NET 

SQL Server 2008 

A 

4 

ITE&C 

Online Government 

Order and Gazette 

goir.ap.gov.in 

Microsoft Technologies 
ASP.NET 

B 

5 

IT E&C 

e-Procurement 

eprocurement.gov.in 

Microsoft Technologies 
ASP.NET 

A 

6 

Home 

e-Cops 

apstatepolice.org/APPW/ 

jsp/homePage.do?metho 

d=getHomePageElement 

s 

Open source 

Technologies 

Java &jsp 

A 

7 

Transport 

CFST- Transport 
Department Services 

www.aotransDort.ora 

Microsoft Technologies 
ASP.NET 

A 

8 

Commercial 

Tax 

e-Return & CDSC 

apct.gov.in 

Microsoft Technologies 
ASP.NET 

A 

9 

Rural 

Development 

MGNREGS- 

Mahatma Gandhi 

National Rural 
Employment 
Guarantee Scheme 

mgnregs.ap.gov.in 

Microsoft Technologies 
ASP.NET 

A 

10 

Health 

Arogyasree - Health 
Insurance and 

Treatment Portal 

aarogyasri.org 

Open source 

Technologies 

Java &jsp 

B 

11 

School 

Education 

SSC examination 
and portal services 

andhraeducation.net 

Microsoft Technologies 
ASP.NET 

C 

12 

Public Service 

Commission 

APPSC - Online 
Application 

Submission 

apspsc.gov.in 

Open source 

Technologies 

Java 

A 

13 

Social Welfare 

Online Post Metrics 
scholarship 

www.aosmfc.com 

Open source 

Technologies 

Java &jsp 

A 

14 

Social Welfare 

ePass 

epass.egg.gov.in 

OS: Linux 

DB: PostgreSQL 8.x 

SW: Java, Struts frame 
work 

Browser: Mozilla, 
GoogleCrome 

A 
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15 

IGRS (Inspector 
General of 
Registration & 
Stamps), 
Department of 
Registration 

CARD 

(Computerized 
Administration of 
Registration 
Department) & CCA 
(CARD Central 
Architecture) 

registration.ap.gov.in 

Web based technology 
using both Oracle 
Forms-llg & Java over 
Linux & Oracle 

RDBMSIlg 

B 

16 

District 

Collectorates 

PRAJAVANI 

prajavani.ap.nic.in 

ASP and SQL Server 

Web Server: IIS 

Telugu support: CDAC- 
GIST Free keyboard 
driver 

A 

17 

Revenue 

WEB LAND 

webland. ap.gov.in 

ASP.NET and SQL 

Server 

B 

18 

Commissioner, 
Food & Civil 
Supplies 

Electronic Public 
Distribution System 
(ePDS) 

epds.ap.gov.in/epdsAP/e 

pds 

Jboss Server for hosting 
Java Wicket framework 
application 

PostgreSQL database 

B 

19 

Commissioner 

and Director of 

Municipal 

Administration 

and 

Commissioner 
of Panchayat 

Raj and Rural 
Employment 

Unified Birth and 

Death Registrations 


Java - Struts Framework 
using MVC Architecture 
Oracle 10g Database 

B 

20 

Rural 

Development 
and Panchayath 
Raj 

Rajiv YuvaKiranalu 
(RYK) 

ryk.cgg.gov.in 

OS: Linux 

DB: PostgreSQL 8.x 

Other Software: Java, 
Struts frame work 

Browser: Mozilla, 
GoogleCrome 

A 

21 

All Welfare 
Departments 

Hostel Monitoring 
System 

welfarehostels.cgg.gov.in 

OS: Linux 

DB: PostgreSQL 8.x 

Other Software: Java, 
Struts frame work 

Browser: Browser 
Independent (compatible 
with any browser) 

B 
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22 Directorate of 
Works 
Accounts, 
Finance 
Department 


Bills Monitoring 
System 


dwabms.cgg.gov.in 


OS: Windows Server 
DB: Oracle 9i 
Other Software: Microsoft 
.NET, Visual Studio 2005 
Browser Independent 


23 

A. P. State 
Housing 
Corporation 
Limited 

1. Housing Online 
Monitoring e- 
Governance System 

2. Urban Housing 
System 

housing.egg.gov.in 

urbanhousing.apcgg.gov. 

in 

OS: Linux 

DB: PostgreSQL 8.x 

Other Software: Java, 
Struts frame work 

Browser Independent 

.Net technologies 

SQL Server 2005, 

Windows Server 2003 
Active Directory, 

SQL Reporting Services 

B 

24 Andhra Pradesh Online Ex- www.aosainikwelfare.aov OS: Linux C 

Sainik Welfare Servicemen Jn DB: PostgreSQL 8.x 

Department Information System Other Software: Java 

25 

Northern Power 

Distribution 
Company of 

A.P Ltd., 
Warangal 

Rythu Mithra(RM) 
call center 

210.212.223.88:8000/RM 

2 

Web based Java 

application with Oracle 
data base 

C 

26 Hyderabad Water Tankers www.hyderabadwater.go ERP application (n-tier B 

Metropolitan Management System v.in/wwo/ architecture) acting as a 

Water Supply backend 

and Sewerage IVRS system providing 

Board-(MA & customer interface to field 

UD Dept.) officers 

27 

Civil Supplies- 
Guntur 

Hostel & Mid-Day 
Meals Rice Allotment 
System 

www.gunturegovernance 

.com 

Microsoft .NET. 

C 

28 Women, SMS based mobile maa.nic.in Open Source B 

Children, application for Technologies 

Disabled and Anganwadis - MAA 

Senior Citizens 

29 

Women 
development 
and child 

welfare 

department 

Girl Child Protection 
Scheme (GCPS) 

gcps.ap.nic.in 

Open Source 

Technologies 

C 

30 Women, m-foods mfoods.ap.nic.in Open Source B 

Children Technologies 

Welfare 

Department 
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S. Department 

No 

Project Name Website Technology Categ 

ory 

31 

Health Medical 
& Family 

Welfare 

Vaccination 
Appointment for 
International 

Travelers 

ipm.ap.nic.in 

Open Source 

Technologies 

C 


Category A: Ready to be used in the Roadmap for APSEA, with minor modifications 
Category B : Can be used in the Roadmap for APSEA with major modifications 
Category C : Can’t be retained in APSEA due to low volume, non-standard development. 
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Annexure IV 


Indicative Scope of Work of Enterprise Architect 


SI No 

Reference in 

this Document 

Description of Work 

1 

Section 1 

Conduct an ABC analysis and identify the departments and agencies 
collectively contributing to 80% of the business of Governance, and to be 
included in the scope of APSEA 

2 

Section 1 

Conduct a Visioning Workshop with the major stakeholders of APSEA 
and define the Vision of APSEA. 

3 

Section 4 

Design the TO BE Enterprise Business Architecture, after analyzing all 
the major G2C, C2G, G2B, B2G, G2E and E2G relationships, both in 
quantitative and qualitative terms. 

4 

Section 4A 

To prepare a more exhaustive list of Common, Group and Cross-cutting 
Applications (than the list given in Section 4A) 

5 

Section 4B.4 

To re-engineer top 20 Elemental Government Processes, for enhancing 
their efficiency, effectiveness and transparency. 

6 

Section 5.1 

Design the Database Schemas for the 4 Core Databases and the Master 
Datasets. 

7 

Section 5.2 

Identify and create Master Datasets for all major domains of the 
Government 

8 

Section 5.5 

Design the Conceptual, Logical and Physical Data Models for APSEA 

9 

Section 5.6 

Design the Data Access Model, Data Lifecycle Model, Data Security 
Model and Data Migration Model for APSEA 

10 

Section 5.7 

Design the Metadata for APSEA 

11 

Section 5.8 

Design the Change Management Plan for Data Migration 

12 

Section 7 

Design the Target Application Architecture for APSEA 

13 

Section 7.6 

Prepare an exhaustive list of target portfolio of Cross-cutting Applications 

14 

Section 7.7 

Design the Application Migration and Change Management Plan 

15 

Section 7 

Undertake the 5 responsibilities listed at the end of Section 5, especially 
designing all the UML Diagrams to form part of APSEA 

16 

Section 8 

To prepare a complete list of existing citizen services that can be 
eliminated through BPR and integration and suggest the steps to be 
taken for the same. 

17 

Section 8 

Prepare a detailed design for the e-Highway (Figure 3) 

18 

Section 8.4 

Design the Enterprise Network Architecture 

19 

Section 8.5 

Prepare a Roadmap for migrating existing application to the Cloud. 

20 

Section 9 

Design an appropriate Governance Structure for implementing the 
APSEA 

21 

Section 9 

Designing an Application Prioritization Plan for implementation, adopting 
the 80-20 Rule and the Criticality-Feasibility principle. 

22 

Section 

Designing the Enterprise Architectures for the Domains/ Applications/ 
Services selected to be implemented in Phase 1, numbering about 20. 
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Annexure V 

Issues in Creation and Maintenance of the Core Database of People 

The following are the issues arising out of the attempt to create and maintain the Core Database of 
People. 

Issue #1 : What is the SOURCE of the People Data? 

Response: For any database to be relied upon by the Enterprise as a Core Data, it has to be 
Authentic, Reliable, Consistent, Real-time, standards-based and Technologically sound. Aadhar stands 
well on all these grounds except he first attribute namely, authenticity, since the data collection and 
entry was done through private agencies. However, this lacuna can be cured through a field 
verification by the Revenue authorities. 

Andhra Pradesh has already created a State Resident Datahub (SRDH) in association with the UIDAI. 
The SRDH mirrors the Aadhar data relating to AP from the Data Repository of UIDAI in Bangalore/ 
Manesar. The data is updated at a defined periodicity. 

Issue #2:What is the Basic Data that Aadhar gives? 

Response: The Basic Data on any resident that Aadhar has, contains the following fields: 

1. Unique Aadhar Number 

2. Name 

3. Father’s Name 

4. Date of Birth or Year of Birth 

5. Sex 

6. Address 

7. Postal PIN code 

8. Photo 

9. Biometric data (10 fingerprints + Iris) 

While UIDAI has shared the data elements from 1 to 8, the biometric data is available for a case-to- 
case online validation. 

Issue #3: What other Socio-economic data of Persons is needed, to make a practical use of the Basic 
Data of Aadhar? 

Response: The following data elements need to be part of the Socio-economic a of persons so that the 
core data of People can be effectively used. 

1. Social Category 

2. LPG/Water / Electricity Consumer numbers 

3. Ration Card Number 

4. Mobile Number 

5. Status of Housing 

6. Status of ISL 

7. Members of the Family 
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8. Education 

9. Employment 

10. Disability, if any 

11. Land held 

12. Livestock 

13. Vehicle 

14. Driving License number 

Issue #4: How do we collect the Socio-economic data? 

Response: There are two methods to collect the Socio-economic data of an individual w.r.t his/her 
Aadhar number: 

Method 1: Seed Aadhar in the databases of all the Socio-economic development 
programs of the Government, by matching records w.r.t place of residence and name. 
This can be tedious and time-consuming. 

Method 2: Smart Pulse Survey Method: Conduct a massively parallel survey of all 
households, and capture the required socio-economic data directly in digital form, with 
online validations. The field surveyors can enter the data by accessing the relevant 
portal through a connected tablet so that (i) the data validations happens on the fly and 
the scope for mistakes is minimized and (ii) the consolidation and analysis of data can 
be completed within 2 weeks of the completion of field survey. 

On account of the drive undertaken by GoAP during June-Aug 14, seeding of Aadhar in 7 major 
departmental databases is likely to be completed soon. However, the aggregate of data entered by the 
7 departments falls short of the socio-economic data requirements indicated in response to Issue #3. In 
view of this, the best strategy is to take the data aggregated by the Aadhar Number may be taken as 
the basis of the Smart Pulse Survey, and appropriate gap-filling done to create the core People 
database. 

Issue #5: How do we keep the Basic data of SRDH updated? 

Response: A combination of 3 methods is recommended to keep the basic (Aadhar) data updated: 

1. A near real-time mirroring of SRDH with the Aadhar database may be attempted; 

2. The permanent Aadhar Enrolment Centres already established in all Mandal Offices in the 
State, may be activated so as to provide opportunity for those not enrolled already to 
register themselves, and to record changes resulting from births and deaths. 

3. Live links may be provided to the registers of marriages, births and deaths to receive 
notifications that can trigger changes in the SRDH, via the Aadhar enrolment process. 

Issue #6: How do we keep the Additional data (Socio-economic data) of SRDH updated? 

Response: A combination of 3 methods is recommended for ensuring that the socio-economic data is 
kept updated on a continuous basis. 
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1. A real-time link is established between the SRDH and all the domain databases dealing with 
people, be it for disbursement of benefits, for providing health and education services or for 
transacting any work with the Government. The changes in the socio-economic profile of the 
individual impacting the ‘additional data, if any, are captured and the additional data in the 
SRDH is updated. 

2. The additional data in SRDH may be used to provide access to selected G2C transactions so 
as to identify any changes and trigger action to verify and authorize the changes to the 
SRDH. 

3. It may also be necessary, for a Smart Pulse Survey to be conducted on a single day once a 
year, to update the additional data. Such an annual survey can be conducted 3 times, by 
which time all the SRDH-based systems are expected to stabilize and get internalized. 

4. The instrument to be canvassed during the Smart Pulse Survey, and the processes 
associated with it shall be so designed as to identify benami records, ineligible beneficiaries 
and grievances of the people, which need to be addressed in a closely monitored manner. 

5. Given the complexities, it is desirable to conduct the Smart Pulse Survey in ONE District at 
first. 

Issue #7: What Standards are to be followed in respect of the Core Data of People? 

Response: 

(a) The Metadata and Data Standards (MDDS) followed by UIDAI while designing the Aadhar 
database schema may be adopted as the de facto standards for the basic data and the bio¬ 
metric data. 

(b) The MDDS notified for certain other data elements of the socio-economic data may be adopted. 

(c) For all other elements fresh MDDS may be defined. 

Issue #7: How to ensure the Authenticity of the Core Data of People? 

Response: The Smart Pulse Survey recommended in response to Issue # 4 may be conducted under 
the aegis of the Revenue department, including a cross-verification of the veracity of a specified 
percentage of the records by the supervisory staff of the revenue department. Basing on the same, the 
revenue officials at the nominated levels will be required to digitally sign the basic data of the records of 
the SRDH, so as to give them authenticity. A process has also to be put in place for authenticating any 
changes to the SRDH records, as envisaged in response to Issue # 6. 

Issue #8: What is the legal sanctity of the Core Data of People? 

Response: An appropriate provision may be made in the legislation proposed on Electronic Delivery of 
Services, on the creation, maintenance and management of the People Data. 

Issue #9: Who shall own and manage the Core Data of People? 

Response: The Revenue Department shall own the Core Data of People and the ITE&C Department 
shall manage the same. The Additional Data shall be owned and maintained by the concerned line 
departments. 
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Annexure VI 

Issues in Creation and Maintenance of the Core Database of Land 
Issue #1 : We need a Standard Classification of the categories of Land. 

Response: Land can be classified in several different ways, namely, depending on its basic 
(geological) nature, or its usage like agricultural, residential, industrial, covered by water bodies, by 
forest or by structures. There are different approved/notified classifications of land prevalent in the 
revenue, registration and survey departments. It is essential to constitute a multi-departmental team of 
experts to arrive at a Standard classification of land, taking into consideration the requirements of 
various functionalities. 

Issue #2: What are the elements of the Core Data on Land and the source thereof? 

Response: Location, Classification, Extent, Owner, Occupant, Usage and Map are the elements of 
Core Data on Land. Revenue Department is, and shall continue to be the owner of the Core Data on 
Land. 

Issue #3: What are the elements of the Additional attributes of the data on Land and the sources 
thereof? 

Response: As one of the most important factors of production and of economic development, Land 
Data is relevant for several economic transactions and projects. A partial list of the additional attributes 
of Land Data is given below: 

1. Soil Classification 

2. Status of irrigation 

3. Classification as per Zonal Regulations/ Master plan 

4. Nature of Structures on the parcel of land 

5. Transactions affecting land (like sale, mortgage, lease, gift) 

6. State actions affecting land (like acquisition, alienation, allotment, 
construction of public assets/ infrastructure) 

7. Basic (market) value 

8. Survey & sub-division. 

Issue #4: How do we keep the core data on Land updated? 

Response: Core Data on the Land maintained by the Revenue Department shall be declared as the 
‘Single Source of Truth’, by making the necessary statutory changes for the same. A Land Data Hub 
(LDH) shall be created, after following the procedures to be prescribed for purification and protection of 
the land database. Thereafter, all transactions affecting the Core Data on Land shall pass through only 
the LDH and update the LDH, as permitted by law. 

Issue #5: What Standards shall be followed in respect of the Core data on Land? 

Response: MDDS shall be defined for the attributes of Land - both basic and additional. 
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Annexure VII 

Issues in Creation and Maintenance of the Core Database of Entities 

Issue #1 : What are the different types of Entities that are required to be handled in e-Governance ? 

Response: The major types of Entities, in terms of their legal status, are Companies, Societies, 
Partnership Firms, Proprietary Firms, Trusts, Statutory Bodies and Public Sector Undertakings. 
Government Departments can also logically be classified as Entities, and given a code so as to make it 
efficient to refer to them in a standard way across the Government. 

Issue #2: What are the sources of the Core Data on Entities? 

Response: Registrar of Companies (RoC), Registrar Of Societies (RoS), District Registrar of 
Assurances (for Trusts and Partnership Firms), Local Bodies (for proprietary firms) and Departments of 
Commercial Taxes, Labour, Income Tax and Central Excise. 

Issue #3: What Data Structure and data Standards shall be followed in respect of the Core Data on 
Entities? 

Response: The Standards and MDDS followed by MCA21 may be taken as de facto standards. Where 
some data elements are not found to be part of the MCA21 database schema, fresh MDDS may be 
defined for the same. 

Issue #4: How do we create Core Data on Entities? 

Response: The following steps are involved in creating the Core Data on Entities 

1 . Create a State Entity Data Hub (SEDH), by defining its Database Schema, keeping in view the 
response to Issue #3. 

2. Create a Unique Entity Number for each entity, (it may be decided separately whether such 
unique number is to be used only within the system for linking/ integrating databases OR to be 
given out to the concerned entities for regular usage, like Aadhar) 

3. Populate the SEDH, by taking the data from 

Issue #5: Who are the expected users of the SEDH? 

Response: Departments of Commercial Taxes, ULBs, PRIS, Regulators, Utilities and Sector Promotion 
Agencies. e-Highway shall be used for this purpose. 

Issue #6: How do we keep the Core Data on Entities updated? 

Response: All statutory processes involving creation/ registration of new entities and closure of existing 
entities shall be routed through the SEDH and an successful completion of each such transaction, 
update the Core Data in the SEDH. 
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